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ABSTRACT 

There  is  significant  confusion  in  the  space  industry 
today  over  the  terms  used  to  describe  satellite  bus 
architectures.  Terms  such  as  “standard  bus”  (or 
“common  bus”),  “modular  bus”  and  “plug-and-play 
bus”  are  often  used  with  little  understanding  of  what  the 
terms  actually  mean,  and  even  less  understanding  of 
what  the  differences  in  these  space  architectures  mean. 
It  may  seem  that  these  terms  are  subtle  differentiators, 
but  in  reality  these  terms  describe  radically  different 
ways  to  design,  build,  test,  and  operate  satellites. 
Furthermore,  these  terms  imply  very  different  business 
models  for  the  acquisition,  operation,  and  sustainment 
of  space  systems.  This  paper  will  define  and  describe 
the  difference  between  “standard  buses”,  “modular 
buses”  and  “plug-and-play  buses”;  giving  examples  of 
each  kind  with  a  cost/benefit  discussion  of  each  type. 

1.  INTRODUCTION 

It  must  be  recognized  that  a  consumer  of  space  products 
does  not  care  what  type  of  spacecraft  bus  was  used  to 
produce  their  product.  The  consumer  cares  only  about 
the  value  proposition  for  that  space  product;  that  is, 
“what  the  consumer  gets  for  the  price  he  pays”.  This 
can  be  thought  of  as  the  value  of  the  product  divided  by 
the  cost.  This  paper  will  assess  the  impact  of  the 
spacecraft  bus  architecture  on  the  consumer’s  value 
proposition  for  space  products.  This  will  be  assessed  by 
comparing  the  inherent  ability  of  the  three  bus 
architectures  (standard  bus,  modular  bus,  and  plug-and- 
play  bus)  to  increase  the  consumer’s  value  proposition 
thru  either  providing  increased  capability,  reduced  cost, 
or  reduced  development  time.  The  three  spacecraft  bus 
architectures  will  be  assessed  against  each  of  the 
following  cost  reduction  strategies:  economies  of  scale, 
the  application  of  a  learning  curve,  smoothing  out  the 
supply  chain  for  parts,  reducing  parts  inventory,  and 
reducing  complexity.  The  value  of  the  space  product  is 
also  influenced  by  the  spacecraft  bus  architecture.  The 
impact  of  the  three  spacecraft  bus  architectures  on  each 
of  the  following  value  improvement  strategies  will  be 
assessed:  increased  flexibility  to  meet  a  wide  range  of 


needs,  rapid  incorporation  of  new  technologies,  and 
decreased  time  to  need. 

This  paper  will  provide  a  qualitative  comparison  of  a 
standard  bus,  a  modular  bus,  and  a  plug-and-play  bus 
architecture  to  a  consumer’s  value  proposition  for  space 
products.  It  will  show  that  the  development  of  a  true 
plug-and-play  capability  for  satellites  will  provide 
significant  payoff;  although  the  investment  required  to 
fully  develop  the  enabling  hardware  and  software  will 
be  significant. 

2.  DEFINITION  OF  BUS  TYPES 

The  first  task  in  eliminating  confusion  surrounding  this 
topic  is  to  define  the  terms  being  used.  For  the  purposes 
of  this  paper  the  following  definitions  will  be  used  (for 
an  in-depth  description  of  historical  review  of  standard 
and  modular  bus  development  efforts  see  [1]): 

•  Standard  Bus:  A  bus  with  a  standard  launch  vehicle 
and  payload  interface  that  can  be  purchased 
unaltered.  The  expectation  is  that  the  bus  can  be 
purchased  by  the  government  and  delivered  to  a 
systems  integrator  for  integration  with  the  payload 
and  subsequent  testing. 

•  Customizable  Bus:  A  bus  from  a  standard  product 
line  that  is  modified  to  meet  specific  mission  needs. 
This  category  includes  most  of  what  industry  today 
calls  a  standard  bus. 

•  Modular  Bus:  A  bus  that  is  assembled  from 
modular  components  with  standard  interfaces  and 
minimal  interdependencies  between  modules.  In 
the  early  developmental  states,  extensive  system 
integration  and  testing  is  required. 

•  Plug-and-Play  Bus:  A  modular  bus  with  open- 
standards  and  interfaces,  self-describing 
components,  and  an  auto-configuring  system. 
System  integration  is  simple  and  testing  tasks  are 
automated.  There  are  two  key  differences  between 
a  Plug-and-Play  satellite  bus  and  spacecraft  that 
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have  been  previously  developed.  That  is:  1.)  the 
use  of  auto-configuring  hardware  and  software 
interfaces  between  the  modules,  and  2.)  these 
interface  standards  are  described  by  Open-  System 
Standards. 

According  to  the  US  DoD  Open-Systems  Joint  Task 
Force  the  definition  of  an  open  system  is  [2]: 

A  System  That  Employs  Modular  Design,  Uses  Widely 
Supported  and  Consensus  Based  Standards  for  its  Key 
Interfaces,  and  Has  Been  Subjected  to  Successful 
Validation  and  Verification  Tests  to  Ensure  the 
conformity  of  component  and  interfaces  to  the 
standards. 

Further,  they  define  the  key  characteristics  of  an  open- 
system  as  one  that  is  : 

•  Based  on  publicly  available  specifications. 

preferably  maintained  as  standards  by 
internationally  recognized  governing  groups 

•  Well-defined,  widely  used  Non-Proprietary 
interfaces,  services,  formats 

•  Durable  (stable  or  slowly  evolving!  Component 

Interfaces,  that  facilitate  [rapid]  component 
replacement  and  addition  of  new  capabilities 

•  Upgradeable.  Through  incorporation  of  additional 
or  more  capable  components  With  Minimal  Impact 
on  the  system 

With  this  definition  we  must  also  spend  a  minute  to 
describe  the  type  of  “key  interfaces”  in  a  spacecraft 
bus.  These  are: 

Mechanical  interfaces  that  describe  volume, 
mass,  physical  connections  and  alignment 
Power  interfaces  that  define  current  and 
voltage 

Data  interfaces  that  describe  data  format,  data 
throughput  and  logic 

Thermal  interfaces  that  define  heat  transfer 
properties  and  allowed  temperatures, 
Environmental  interfaces  -  EMI,  radiation, 
outgassing  allowed 

It  is  also  useful  to  define  the  term  modular-design  or  a 
module.  This  is  a  design  approach  based  on  dividing  a 
system  into  smaller  parts  (or  modules)  that  can  be 
created  independently  and  assembled  together  to 
achieve  the  performance  required  of  the  complete 
system.  In  general  a  modular  design  results  in 
reduction  in  cost  due  to  the  ability  to  develop  modules 
in  parallel  rather  than  one  complex  system  developed  in 
serial,  and  due  to  the  ability  to  re-use  the  components  in 
multiple  combinations.  Modular  design  is  an  attempt  to 
combine  the  advantages  of  standardization  (high  volume 
normally  equated  with  low  manufacturing  costs)  with 
those  of  customization  [3]. 


3.  METHODS  FOR  INCREASING  THE 
VALUE  PROPOSITION 

In  “Economics  of  Strategy”  the  value  proposition  is 
defined  as  the  sum  total  of  benefits  a  customer  receives 
in  return  for  the  customer's  associated  payment  (or  other 
value-transfer)  [4],  In  simple  words  the  value 
proposition  is  what  the  customer  gets  for  what  the 
customer  pays.  That  is: 

Customer  .benefit 

Value .  proposition  = - 

Cost 

(i) 

Thus  to  increase  the  value  proposition  for  a  product  one 
must  either  reduce  the  cost  of  the  product,  add  customer 
benefit,  or  both.  So  let  us  examine  each  of  these 
variables  in  turn.  The  well  known  ways  to  reduce  the 
cost  of  a  product  include: 

Utilize  economies  of  scale  and  scope  to  spread 
fixed  costs  over  a  greater  number  of  units 
Application  of  a  learning  curve  to  reduce 
variable  costs  by  doing  the  same  thing 
repetitively 

Smooth  the  supply  chain  to  lower  vendor  costs 

Reduce  inventory  costs 

Reduce  or  manage  complexity  in  the  system 

There  are  several  well  known  ways  to  add  customer 
benefit  (or  customer  value)  to  a  product.  The  first  way 
is  to  increase  the  flexibility  (scope  or  number  of 
potential  applications)  of  the  product.  This  allows  the 
product  to  meet  a  wider  variety  of  the  customer’s  needs. 
Flexibility  allows  the  customer  to  utilize  the  product  to 
respond  to  uncertainty  or  changes  in  threats  or 
opportunities.  Another  way  to  add  value  to  a  product  is 
by  increasing  the  number  of  modules  which  in  turn 
increases  the  options  to  incorporate  new  innovations. 
This  is  simplified  in  a  modular  architecture  because  the 
interdependencies  between  components  are  decoupled, 
permitting  innovation  at  the  module  level.  This 
decoupling  enables  development  to  take  place  in 
parallel  at  the  module  level.  This  provides 
differentiation  to  the  producer  of  a  product  in  a  tight 
market-place  and  allows  that  producer  to  reduce  time  to 
market  for  new  capabilities  [5].  According  to  Clark  and 
Baldwin  [3],  the  value  of  adding  modules  (or  splitting) 
a  system  is  proportional  to  the  square  root  of  the  number 
of  modules.  Thus  the  option  value  of  a  system  with  25 
modules  has  5  times  the  value  of  an  unitary  system.  It 
is  clear  that  one  powerful  method  to  increase  the  value 
proposition  of  a  complex  system  like  a  spacecraft  bus  is 
thru  the  use  of  modular-design  practices. 


4.  COMPLEXITY:  THEORY  OF  DESIGN 

When  assessing  acquisition  models  for  complex  systems 
it  is  useful  to  review  the  Design  Structure  Matrix 
method  [8],  Complexity  in  these  systems  is  often 
viewed  as  an  obstacle  to  the  design  and  development  of 
innovative  products.  However,  complexity  in  systems 
enables  more  capability  and  facilitates  innovations  that 
would  not  be  possible  otherwise.  Therefore  complexity 
management  becomes  critically  important  to  achieving 
product  development  goals.  The  Design  Structure 
Matrix  is  one  approach  developed  to  manage  the  design 
and  optimization  of  complex  technical  systems. 


Coupled  elements  that  span  multiple 
companies 

o  These  dependencies  require  inter¬ 
company  coordination  resulting  in 
high  transaction  and  agency  costs, 
contracts,  SOW’s,  ICD’s,  travel,  etc.. 
Coupled  elements  that  span  multiple 
governmental  organizations 

o  These  dependencies  require 
negotiated  approvals,  coordination 
and  compromise  of  system  goals, 
funding  coordination,  alignment  of  of 
stakeholders 


In  the  Design  Structure  Matrix  method  there  are  three 
types  of  dependencies  between  activities  or  system 
elements  A  and  B  within  complex  systems.  (1)  Parallel 
or  modular:  in  this  case  A  is  independent  of  B  and  no 
information  exchange  is  required  between  the 
development  of  the  two  system  elements.  (2) 
Sequential:  in  this  case  A  influences  B.  A  must  be 
completed  before  B.  (3)  Coupled  or  interdependen:.  in 
this  case  A  influences  B  and  vice  versa.  Resolving  this 
interdependency  requires  an  iterative  design  process  of 
trades  and  analyses.  These  dependencies  are 
represented  with  the  following  schematic: 
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The  trend  in  Design  Complexity  from  the  least  complex 
process  to  the  most  complex  process  from  a  technical, 
management,  and  organizational  view  is: 

independent  parallel  system  elements 

sequential  elements 

Coupled  elements  within  a  component 

o  These  dependencies  can  be  solved  by 
an  individual  or  informal  working 
group 

Coupled  elements  that  span  multiple 
components 

o  These  dependencies  must  by  solved 
with  systems  engineering  working 
groups 

Coupled  elements  that  span  multiple 
departments  within  an  organization 

o  These  dependencies  require  inter¬ 
departmental  coordination,  often 
resulting  in  multiple  meetings, 
rivalries  and  turf-wars 


It  is  clear  that  spacecraft  development  today  falls  into 
the  most  complex  case  specified  above.  That  is 
development  of  the  spacecraft  system  span  multiple 
companies  and  multiple  government  organizations. 
This  results  in  a  lengthy  requirement  generation 
processes,  lengthy  and  costly  design,  development  and 
testing  processes,  significant  management  burden,  and 
ultimately  compromises  that  lead  to  dissatisfaction  by 
the  users  of  the  system. 

The  Theory  of  Design  Complexity  shows  that  by 
incorporating  a  modular-design  process  applied  to 
spacecraft  development  and  acquisition  decouples  many 
design  elements  and  results  in  simplified  coordination 
of  tasks  andy  decision  making.  Modularity  in  the 
system  allows  for  maximum  re-use  of  components,  and 
for  parallel  development  [5,  6], 


5.  DO  STANDARDS  RESTRICT 
INNOVATION? 

It  is  often  claimed  that  “standardization  prevents 
innovation”.  In  fact  this  is  far  from  reality.  A  study  of 
four  case  histories  in  various  domains  -  manufacturing, 
computer  hardware,  mechanical  component  design,  and 
product  data  exchange  reveals  that...  innovation  is 
often  spurred  -  directly  and  indirectly  -  from 
standards  [7,8,  9]. 

Jorma  Ollila,  the  Chairman  of  Nokia’s  Board  of 
Directors  reinforced  this  notion  when  he  stated,  “... 
Open  standards  and  platforms  create  a  foundation  for 
success.  They  enable  interoperability  of  technologies 
and  encourage  innovativeness  and  healthy 
competition,  which  in  turn  increases  consumer  choice 
and  opens  entirely  new  markets."  [8]  The  EU 
Commissioner  Erkki  Liikanen  also  stated,  "Open 
standards  are  important  to  help  create  interoperable  and 
affordable  solutions  for  everybody.  They  also  promote 
competition  by  setting  up  a  technical  playing  field  that 
is  level  to  all  market  players.  This  means  lower  costs  for 
enterprises  and,  ultimately,  the  consumer. " 


It  is  clear  that  standardization  and  use  of  modular- 
design  rules  do  not  restrict  competition  and  innovation. 
In  fact,  they  are  a  key  component  to  stimulating 
innovation. 

6.  COMPARISON  OF  SPACECRAFT  BUS 
TYPES 

In  order  to  compare  the  value  proposition  of  spacecraft 
bus  types,  the  two  types  representing  proposed 
approaches  for  building  responsive  space  busses  of  the 
possibilities  will  be  qualitatively  compared.  That  is  a 
Standard  Bus  and  a  Plug-and-Play  Bus.  The 
comparison  will  be  based  on  a  life-cycle  of  20  years.  It 
will  be  assumed  that  the  technology  life-cycle  of  the 
components  in  the  spacecraft  bus  is  5  years. 

6.1. Standard  Bus  Acquisition  Approach 

Several  studies  have  found  that  spacecraft  bus 
requirements  for  a  large  majority  of  responsive  space 
missions  can  be  encompassed  with  three  basic  bus 
designs::  a  spacecraft  bus  for  high-precision  pointing 
Low-Earth-Orbiting  missions  (LEO  HPP);  a  spacecraft 
bus  for  medium  precision  pointing  Highly  Elliptical 
earth-Orbiting  missions  (HEO  MPP);  and  a  spacecraft 
bus  with  minimal  pointing  requirements  but  a  high 
degree  of  maneuvering  capability  for  LEO  servicing  and 
inspection  missions.  Thus  it  will  be  assumed  that  three 
separate  spacecraft  buses  are  required  and  sufficient  to 
meet  all  mission  requirements  for  a  given  customer. 
Assuming  a  technology  obsolescence  of  five  years,  this 
means  that  six  new  spacecraft  designs  must  be  produced 
every  10  years.  Thus  over  a  20  year  life-cycle  12  new 
spacecraft  would  have  to  be  redesigned  for  this 
customer.  Further  assuming  that  50  satellites  were 
purchased  in  the  first  decade  (for  a  flight  rate  of  5 
flights  per  year),  this  would  imply  that  8  missions  were 
flown  per  each  spacecraft  bus  design.  If  in  the  second 
decade  140  satellites  were  purchased,  there  would  be 
roughly  23  missions  per  each  spacecraft  bus  design. 
Given  today’s  flight  rates  for  spacecraft  missions  this 
would  represent  the  best-case  scenario  for  leveraging 
economies  of  scale. 

If  it  is  assumed  that  there  is  an  18  month  lead  time  on 
components  for  spacecraft  (as  is  the  norm  for  critical 
spacecraft  components  today),  then  it  is  given  that 
mission  types  and  bus  capabilities  must  be  locked-in  at 
the  start  of  a  6.5  year  period.  At  the  beginning  of  this 
6.5  year  period  the  customer  must  also  plan  for  the 
proper  number  of  buses  to  support  each  mission  type. 
That  is  X  copies  of  bus  A,  Y  copies  of  bus  B,  and  Z 
copies  of  bus  C.  All  of  the  nonrecurring  costs  and  the 
inventory  costs  are  incurred  in  the  beginning  of  the  6.5 
year  period.  There  is  also  a  strong  potential  for  waste  in 


this  model  as  the  pre-selected  quantity  of  buses  A,  B, 
and  C  may  be  in  excess  of  the  actual  need,  also 
requiring  the  development  of  additional  buses  of  other 
needed  types.  Because  of  the  lead  time  in  procuring 
long  lead  hardware,  and  construction  time,  this  creates  a 
critical  problem  when  there  are  not  enough  buses  of  a 
specific  type  to  meet  the  needs  of  the  customer. 

This  acquisition  approach  has  negative  impact  on 
supply  chain  management.  The  supply  chain  has  bursts 
of  activity  followed  by  long  periods  of  inactivity.  These 
bursts  are  driven  by  the  5  year  technology  obsolescence 
cycle  and  the  desire  to  utilize  economies  of  scale  during 
production.  In  this  acquisition  model  the  component 
vendors  must  structure  their  organization  for  feast  or 
famine.  In  addition  the  time  horizon  for  return  on 
component  innovations  is  long  and  uncertain. 

6. 2. Modular  PnP  Bus  Acquisition 
Approach 

The  PnP  Bus  Acquisition  Model  assumes  that  spacecraft 
are  “modularized”  and  there  is  no  one  distinct  spacecraft 
bus  design.  Rather,  there  are  a  bounded  series  of 
spacecraft  modules  or  components  that  can  be  quickly 
integrated  into  a  variety  of  combinations  since  a 
common  spacecraft  “architecture”  is  used  for  each 
combination.  That  is  a  common  set  of  physical, 
electrical,  thermal,  and  data  standards  are  used  for  each 
spacecraft  bus  configuration  and  a  common,  reusable, 
modular  flight  software  library  is  utilized.  Spacecraft 
bus  configurations  can  be  pre-designed  and  tested  prior 
to  being  needed  and  left  as  unassembled  components. 
The  spacecraft  can  then  be  assembled  as  needed. 
Economies  of  scope  and  learning-curve  benefits  still 
apply  since  the  same  common  spacecraft  “architecture” 
is  used  for  each  mission  and  components  can  be  used 
for  more  than  one  specific  mission  type. 

The  PnP  Bus  Acquisition  Model  has  significant  impact 
on  inventory  management.  First,  it  is  likely  that  a  wider 
range  of  components  will  be  held  in  inventory  than  for  a 
standard  spacecraft  bus  acquisition  model.  For 
example,  there  may  be  multiple  battery  capacities  in  the 
PnP  Acquisition  Model  since  it  is  relatively  trivial  in 
this  model  to  “customize”  spacecraft  bus  performance 
simply  by  interchanging  a  spacecraft  component.  This 
would  require  a  greater  focus  on  logistics  and  inventory 
management.  However,  the  benefit  to  this  approach  is 
that  it  would  be  possible  to  turnover  the  inventory  more 
quickly  and  rapidly  incorporate  a  new  innovation  in 
battery  performance.  In  fact,  in  this  approach  the 
demand  prediction  horizon  is  moved  from  6.5  years  for 
a  standard  bus  acquisition  model  (assuming  18  month 
component  lead-teams  and  a  five-year  bus  life-cycle)  to 
an  1 8  month  lead  time.  So,  in  the  PnP  Bus  Acquisition 
Model  the  customer  must  plan  and  inventory  for  18 


months  of  future  years  needs  vice  6.5  years  for  a 
standard  bus  acquisition  approach.  This  benefits  the 
component  suppliers,  as  they  can  structure  their 
organization  for  continuous  development  and 
production,  One  final  important  factor  for  inventory 
management  is  that  for  the  true  PnP  Bus  Acquisition 
Model  to  be  implemented  system  integration  and  testing 
must  become  trivial.  At  that  point  module-level  testing 
is  sufficient  to  guarantee  performance  of  the  spacecraft 
bus.  Inventory  management  procedures  must  develop 
processes  and  procedures  to  ensure  component  level 
performance,  health  and  reliability. 

There  is  the  potential  for  some  waste  in  this  acquisition 
model  as  there  is  in  the  standard  bus  acquisition  model. 
However  in  this  case  the  waste  is  driven  by  the  length  of 
the  component  lead-time  (18  months)  versus  a  6.5  year 
block  development  time  as  for  the  standard  bus 
acquisition  model.  So,  as  previously  discussed,  the 
developer  has  to  predict  only  18  months  of  demand  vice 
6.5  years  of  demand. 

In  the  PnP  Bus  Acquisition  Model  new  technologies  can 
be  incorporated  into  the  system  with  minimal  impact  on 
the  rest  of  the  design  (so  long  as  the  new  technologies 
do  not  violate  the  specified  component  interface 
standards).  Spacecraft  bus  designs  can  evolve  in  a 
continuous  fashion  to  incorporate  new  technologies  or 
mission  needs.  Perhaps  the  most  important  effect  of 
moving  to  a  PnP  Bus  Acquisition  Model  is  to  force 
maximum  re-use  of  designs,  hardware,  and  software. 
This  has  been  proven  in  many  high-volume  industries 
such  as  personal  computing  and  automobiles  and  in 
low-volume  industries  such  as  supercomputers,  and 
high-performance  interruptible  power  supplies  to 
drastically  reduce  the  cost  of  producing  a  new  product 
and  to  drastically  increase  the  differentiation  of  these 
products  from  it’s  competitors  [5]. 

6. 3. Comparison  of  Bus  Acquisition 
Models 

The  comparison  of  these  bus  acquisition  models  is 
summarized  in  the  following  table: 


Table  1.  Comparison  of  Spacecraft  Bus  Acquisition 
Models 


Standard  Bus 

PnP 

Fixed  Costs 

Moderate 

High,  dependent  on 
cost  of  developing 
modular  arch. 

Variable 

Costs 

Moderate 

Moderate  to  Low 

Economies  of 
Scale 

At  bus  level 

At  component  level 

Economies  of 
Scope 

Limited,  because 
different  buses  and 
blocks  will  likely 
be  built  by 
different  vendors. 

High.  Open  system 
architecture  used  for 
multiple  missions  over 
a  long  time  span. 

Learning 

Curve 

85%  over  each  bus 
quantity 

85%  over  20  year  total 

Supply  Chain 

Lumpy 

Smooth 

Inventory 

Management 

Build  and  store  5 
yrs  worth  of  buses 
to  take  advantage 
of  economies  of 
scale  in 
manufacturing 

Store  1.5  yrs  of 
components  required  to 
meet  range  of  mission 
requirements 

Complexity 

Low,  controlled  by 
specifying  LV  and 
PLI/Fs 

Low,  controlled  by 
eliminating  parameter 
and  task 

interdependencies 

Flexibility 

Low 

Moderate  to  High 

Option  Value 

Low 

High 

7.  MODULARIZING  IS  EXPENSIVE 

The  previous  analysis  of  spacecraft  bus  acquisition 
models  presents  a  compelling  case  for  the  development 
of  a  modular,  open-systems  “plug-and-play”  capable 
spacecraft  bus  architecture.  It  is  often  argued  that  if  this 
business  model  were  so  compelling  the  industry  would 
have  adopted  it  in  the  late  1970’s  when  the  technologies 
first  became  available  in  the  high-performance 
computing  world.  However,  as  we  know  today  that  did 
not  happen.  Why? 

Ultimately  “modularizing”  a  complex  system  is 
costly.  It  is  costly  in  two  important  ways:  (1)  the 
capital  costs  required  to  develop,  validate,  and 
implementation,  and  (2)  in  cultural  costs.  Let’s 
take  each  of  these  costs  in  order.  First,  an  example 
from  history  highlights  these  costs.  In  the  early 


1960’s  the  computing  industry  looked  very  much 
like  the  spacecraft  market  does  today.  That  is, 
nearly  every  computer  at  the  time  was  unique  and 
was  built  one  at  a  time  from  components  that  were 
highly  coupled  and  interdependent.  In  addition,  the 
market  was  quite  small  and  driven  primarily  by  the 
U.S.  Government.  At  that  time  IBM  engineers 
recognized  there  would  be  substantial  benefit  to 
“modularizing”  their  mainframe  computer  design. 
It  is  estimated  that  IBM  spent  over  $2.5B  in  R&D 
and  over  $20B  total  to  develop  the  IBM 
System/360  (cost  figures  in  2006  dollars).  This  far 
exceeded  the  initial  estimate  to  modularize  the 
mainframe  architecture.  However,  it  is  estimated 
that  in  1970  the  market  value  of  the  IBM 
System/360  exceeded  S190B. 

Secondly,  “modularizing”  a  complex  system  has 
significant  human  capital  cost  and  is  in  fact  counter  to 
the  way  design  of  complex  systems  is  handled  in  most 
companies  and  industries  today.  As  described  in 
Section  4  above,  complex  systems  with  coupled 
elements  that  span  multiple  components 
dependencies  must  by  solved  with  systems  engineering 
working  groups.  Typically  these  working  groups  are 
assigned  to  individual  managers  to  oversee.  These 
managers  are  required  to  trade  risk  against  schedule  and 
resources  to  achieve  the  goals  of  their  specific  working 
group.  Therefore,  they  are  not  incentivized  to  work  on 
projects  that  are  outside  the  scope  of  their  effort;  even  if 
that  effort  would  eventually  benefit  the  overall  product 
development  effort.  Due  to  this  resistance  to  work  on 
projects  for  the  “greater  good”  of  the  overall  system, 
many  companies  have  found  that  the  only  way  to  instil 
“modularization”  in  their  business  is  to  drive  this  from 
the  top  of  the  company.  Several  companies  have 
developed  a  position  for  a  Chief  Innovation  Officer  who 
is  chartered  to  foster  “modularization”  in  their  business 
practices  [5]. 

8.  CONCLUSIONS 

This  assessment  of  spacecraft  bus  types  and  associated 
acquisition  models  shows  that  there  is  potentially  great 
value  in  developing  a  modular,  plug-and-play  spacecraft 
bus  architecture.  However,  based  on  lessons  learned 
from  other  applications  [5],  implementation  wll  have  to 
come  from  outside  the  “normal”  spacecraft  acquisition 
process. 

As  government  organizations  are  the  primary  customers 
today  for  spacecraft  systems,  the  government  space 
enterprise  will  have  to  act  in  the  role  of  Chief 
Innovation  Officer  to  bring  about  this  innovation.  It  is 
also  unclear  what  will  be  the  ultimate  cost  of  achieving 
this  innovation.  However,  it  is  clear  that  if  it  is  achieved 
and  history  is  any  guide,  it  will  pay  tremendous 


dividends  in  reducing  costs  of  spacecraft  in  the  future, 
and  in  advancing  their  capabilities. 
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